1. Field Of The Invention
This invention relates to display memory and, more particularly, to methods and apparatus for utilizing display memory to store off-screen pixel data to which direct graphics access is allowed.
2. History Of The Prior Art
In its simplest form, a computer writes data from a single program to a frame buffer which stores the data so that it may be written to an output display. The data of this single program covers the entire output display. When it is desired to display more than one program at a time on an output display, it is necessary for the computer system to somehow provide different portions of the screen (windows) in which each program may be displayed, direct the information from each program to the correct window, and take care of the overlapping of different windows so that the correct portions of each are presented, among other things.
If all of these tasks are done by individual programs, then there must be a great deal of checking among programs to make sure that the different programs do not interfere with one another. This tends to slow the operation of the system, and allows poorly designed software to distort the operation of the system. For this reason, more advanced computer systems have designed window system programs which take over the entire operation of writing to the frame buffer for control of what is displayed. A window system controls the entire display. It receives requests to display information from the individual application programs, stores those requests in system memory, selects the windows in which different programs may be displayed, translates the requests furnished by the application programs and stored in main memory to text and graphics output to the frame buffer, controls the overlaps of windows, upon request stores the data in the covered portions of windows so that it may be recalled at a later time, and does all operations necessary for the display of a number of programs on a single output display device. This assures that programs operate correctly in presenting their outputs and relieves an application programmer of the necessity of writing many of the procedures for display purposes.
Windows are generally represented as varying sized rectangular pixel areas on the output display. When one window overlaps another, a portion of the pixels from the overlapped window are no longer visible on the output display. When the invisible portion of an overlapped window again becomes visible due to changes in the window overlap arrangements on the output display, the formerly invisible pixel area from this window must be repaired. Sometimes it is possible for the program sending output to this window to repair the newly exposed area. In other cases, usually due to the complexity of the repair, the program would prefer that the window system remember the pixels that previously appeared in this pixel area from its output stream and that the window system take care to retain and restore the pixels as necessary, leaving the program free to ignore any repair operations which might become necessary. Some window systems support this feature through a mechanism called retained windows. Application programs which wish not to be burdened with repairing damaged areas of their windows request this feature from the window system.
Even though window systems have been designed to do all of these things, there are some difficulties with using them. For example, there may be some kinds of graphics operations which the window system does not support. Additionally, a computer system running such a window system program does not operate as rapidly to display information as do individual programs which themselves write directly to the frame buffer. A window system program with its necessary overhead may be able to vary the output display only ten times per second while a live video display requires that it be displayed sixty times per second in order to describe action in a manner which does not appear to the viewer to be distorted.
In order to speed the overall graphics operation, various graphics accelerators have been designed which relieve the central processing unit of many of the graphics display functions and thereby speed the rendering of graphic information to the display. Some computer systems allow data from individual application programs to bypass the window system and be written directly to the graphics accelerators and thereby substantially speed the rendering of graphic images on an output display. Typically, very fast graphics programs will use this facility to speed rendering. However, the window system program is still used in a multitasking environment to control the assignment and manipulation of the windows areas on the display and to control the rendering of graphics images for the other application programs which do not require very fast rendering. Consequently, two individual processes, the window system controlling the placement and movement of the window and the application program providing the data for the window, must share the graphics accelerator hardware for windows to which the application program has direct graphics access.
If multiple processes running on a computer system want to share a piece of hardware that, in order to operate correctly, stores information regarding the state of the process being run (data defining the state of the process, generally referred to simply as "state"), each time a different process wants to use the particular hardware something has to change the state of the hardware. That is, the process currently being run must have its state saved so that the state can be restored in the hardware when the process is to be recommenced in order to continue the process from the point at which it halted. Additionally, the process to be run must have its state restored in the hardware so that the process will run correctly. This operation is generally referred to as saving and restoring state or context switching.
Traditionally, a process would request exclusive use of a particular piece of hardware and use it exclusively for some period of time. In order to obtain this exclusive use, the process would make a call to the operating system. The operating system would conduct a number of checks and ultimately probably accomplish the context switch. Such a call takes a great deal of time and distracts the central processing unit from other functions. When the computer is running a single application program, the time taken is not terribly important since such a call is not used often. However, for computer systems involved in multitasking a number of different application programs simultaneously, the traditional process of system calls from the application programs to accomplish context switching must be utilized quite often and causes a substantial slowing of system operation.
In systems using a plurality of processors (such as a central processor and a floating point processor) which normally require a large amount of context switching, the operating system has long been provided with scheduling facilities which eliminate the need for the calls by the processes to the system in order to accomplish a context switch and thereby reduce the time required. However, such automatic context switching mechanisms were typically not available for the use of other hardware in the system.
Where the processes require the transfer of very large amounts of data as in the simultaneous display of the results of multiple application programs in a plurality of windows on an output display, very extensive context switching is necessary. For example, a graphics accelerator stores state relating to individual application programs being simultaneously displayed in windows on an output display. This state describes, among other things, the position of an individual window, the color mode used by the application program, whether the results to be displayed by the program are being double buffered, and a number of other things. Similarly, the state necessary for the operation of the window system is stored in the graphics accelerator when that process is run.
Normally software in a multitasking environment must be written to either request the exclusive use of all hardware resources it may need for the entire time the process is running, or it must explicitly request the hardware each time it needs to use it. In order to permit maximum sharing of limited hardware resources, well written software generally limits the amount of time it spends holding exclusive access rights to shared hardware. However, since explicit access requests are usually time consuming, most software will place access requests at relatively top levels of code, not actually knowing what kind of accesses, if any, will actually be required. In a multitasking system, if each use of the central processing unit by a process fosters a request for access to the graphics accelerator, the myriad requests by different processes which are time sharing the central processing unit would cause constant context switching even though the graphics hardware were not always required. If each of these requests requires a call to the operating system, then the actual display of the multiple windows will slow drastically due only to the overhead of processing access requests. Even if a system call by an application program is only required for each actual use of the graphics accelerator by a different application program, the requirement is a great waste of time.
Recently, an arrangement for context switching has been devised by which a plurality of processes may utilize hardware devices in addition to the central processor and the math coprocessor without requiring system calls by the application programs. U. S. patent application Ser. No. 07/413,976, entitled Method and Apparatus for the Context Switching of Devices, filed Sep. 28, 1989, D. Rosenthal et al, and assigned to the assignee of the present invention, describes such a system. In accordance with the teaching of the invention, the request for the use of a hardware device by a process and the attendant context switching is moved from a system call into the virtual memory management portion of the system which consists of both hardware and efficient software support already built into and optimized within the operating system. The simple attempt by a process not running on a device to utilize the device triggers a page fault which is automatically handled by the virtual memory management portion of the system to accomplish the context switch. The memory management facilities are already set up to do the context switch efficiently.
Removing the explicit access requests from the application program dramatically reduces the amount of overhead involved in a context switch. The memory management unit calls a device driver for the specific piece of hardware. The device driver is set up to do the context switch as an automatic operation. In the preferred embodiment, if the process never actually accesses a particular hardware device, the context switch of the device never occurs. When used with a graphics accelerator, the process functions to reduce the context switching which takes place and to increase the speed of the context switching which does occur in presenting a plurality of application programs in multiple windows using the graphics accelerator hardware. This new invention has greatly accelerated the context switching necessary for direct graphics access support for multiple graphics application programs running simultaneously.
However, recently a new method has been developed for utilizing excess frame buffer memory to store off-screen data associated with the display. For example, it is often useful to store in off-screen memory a second representation of the data in a graphics window covered by a portion of another window. This second representation provides backup storage (typically referred to as a "retained window") for pixel data in a portion of a window covered by a portion of another window. This pixel data is kept so that it may be restored to the screen if the overlapping window is removed from the covering position. If this off-screen retained window can be stored locally in the display hardware, then the substantial time required to store the data in system memory is saved. Display systems which provide double buffering for application programs offer substantial amounts of unused frame buffer memory during periods in which double buffering is not used. Prior to the recent invention, the allocation of off-screen memory was too slow to allow display memory to be used for this purpose. U.S. patent application Ser. No. 716,671 entitled METHOD FOR ALLOCATING OFF SCREEN DISPLAY MEMORY, McIntyre et.al, filed Jun. 17, 1991, and assigned to the assignee of the present invention discloses in detail a method of making use of this off-screen display memory.
Typically, the window system controls the storage and updating of the retained window pixel data. However, where there is direct graphics access by the application program, the window system has no control over the pixel data and therefore cannot update the data in the currently invisible retained portion of the window to correspond to updates made by the application program to the visible portion of the window. Consequently, stale pixel data may be provided when the window is uncovered. In order to update a covered portion of a window without requiring a call to the application program, it is necessary that the application program using direct graphics access be able to write to the off-screen memory at the same time that it writes to the visible memory. This is especially true when the application has been written without the ability to remember and redraw old output. This dual access is not possible using the arrangement disclosed in the first above-mentioned patent application.
Not only is it useful for the application program to have direct graphics access to off-screen memory in the frame buffer, if double buffering is required for any application program being run on the display, then the off-screen frame buffer space must be provided for this double buffering. In such a case, any retained window or similar off-screen data stored in the excess space of the frame buffer (now being used for double buffering) must be removed to system memory. Consequently, the application program should also have direct graphics access to the retained portion of the window when the data is stored in system memory. And since the window system controls the moving of the off-screen data whether stored in the frame buffer or system memory, it must also have access to this memory. Since the retained window data may be stored in either system memory or off-screen frame buffer memory, both the application program and the window system must be able to deal with the retained window data whether in the frame buffer or the system memory. This requires not only a mechanism for shared access to the pixel data whether in off-screen or system memory but also a method to assure access synchronization and context switching of graphics hardware when in off-screen memory.